Header Compression
Header compression is a method used to compress IP (Internet Protocol) headers, and optionally also TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and RTP (Real-time Transport Protocol) headers, for transmission over e.g. wireless links.
The compression efficiency when using header compression is based on the assumption that many fields in, e.g. the IP headers, contain information that is: static during the whole session; change rarely; or that the changes are predictable. For header fields that do not change, or are changed rarely during a session, it is common to first transmit the information and then uses states to store this information in the transmitter and in the receiver, respectively. Thereby, the static or rarely changing information can be recreated at the receiver, which makes it unnecessary to send this information in every packet. For header fields that change predictably, e.g. if the value is incremented with a fixed amount for each packet, it is common to detect the increment, send the initial value and possibly also the increment in the first packet. The receiver then calculates the value in the field, using the initial value and the increment.
Header Compression Using ROHC
ROHC [1a] provides considerable compression efficiency compared to no compression and many other header compression schemes. A packet containing an RTP/UDP/IPv4 (IP version 4) header (40 octets or bytes) can often be compressed to as little as 2-3 octets, or even 1 octet in some cases.
With ROHC, one typically gets the following overhead for the transmitted packets:                The first packet requires full headers, i.e. the overhead is larger than for uncompressed headers. The full headers may be repeated for a few packets for robustness to packet losses.        For the next few packets it is possible to use reduced headers, since ROHC is able to compress all static information. It may however still take some packets before the increment for the non-static fields has been predicted and before the overhead can be reduced to its minimum.        After a few more packets, when ROHC has been able to estimate the increment to be used for the non-static fields, then the overhead can be reduced to the minimum, usually as little as 1-3 octets.        
The sender can update all fields of the headers at any point in time, even those fields that were assumed to be static. This, however, requires increasing the overhead while the new static information is transmitted. The over-head needed to update static or semi-static information depends on the field which to be updated.
Explicit Congestion Notification (ECN)
ECN is described in [2] and is a method with which routers can inform the receiver that congestion has been detected in a router in the path. For example, for an IP header, two bits are reserved for this purpose. These two bits are used in the following way:
TABLE 1Encoding of ECN bitsECN bitsAbbreviationUsage‘00’Not-ECTSet by sender if it is not ECN capable‘10’ECT(0)May be set by sender if it is ECN capable‘01’ECT(1)May be set by sender if it is ECN capable‘11’ECN-CESet by congested router if incoming packet hadeither ECT(0) or ECT(1)
Senders that are not ECN capable declare this by setting the ECN bits to non-ECT. If an ECN capable router detects not-ECT it is not allowed to mark the packet with ECN-CE. If congestion occurs in the router then it may drop some or many packets.
An ECN capable sender declares that it has “ECN Capable Transport” (ECT) by setting the ECN bits to either ECT(0) or ECT(1). A congested ECN capable router can then indicate congestion by marking the ECN bits with ECN Congestion Experienced (ECN-CE) and then forwarding the packet instead of dropping it.
An ECN capable receiver that detects an ECN-CE marked packet either informs the sender about the detected congestion or initiates methods to reduce the congestion, typically by requesting a reduced bitrate.
The ECN bits are typically part of another field, such as the ToS (Type of Service) octet in IPv4. In IPv6 the ECN bits are part of the Traffic Class field. Today the ToS field constitutes 6 bits for the DiffServ codepoint and 2 bits for ECN.
Relationship between ECN and ROHC
When ROHC was initially designed, the field in which the ECN bits are embedded, for example the ToS octet, was considered to be rarely changing. This means that whenever this octet changes some extra information must be transmitted. This extra information constitutes 5 extra octets of ROHC overhead in addition to the normal overhead of 1-3 octets (in total 6-8 octets of ROHC overhead).
The following ROHC overhead will be used when the ToS field is constant and when it is changing [1b], respectively:                ToS octet constant                    1. UO-0 baseheader (1 octet) [1c]            2. UDP checksum (2 octets), copied from the UDP header                        ToS octet changing                    1. UOR-2 baseheader (3 octets) [1d], the X bit is set to ‘1’ to indicate that the extension is included.            2. Extension [1e], including:                            a) FLAGS octet (1 octet), showing that the included extension uses the Extension 3 format. The ip bit in the FLAGS octet is set to ‘1’ to indicate that the “Inner IP header flags” octet is included.                b) Inner IP header flags (1 octet), with the TOS bit set to ‘1’ indicating that the TOS/TC field is included.                c) TOS/TC field (1 octet), copied from the IP header                                    3. UDP checksum (2 octets), copied from the UDP header                        
As the transmission channel is unreliable, it is common to repeat the extra overhead up to three times for every change. This means that the extra over-head is 5 bytes for three consecutive packets.
It has been studied how much impact the ECN rate (=proportion of ECN-CE marked packets) have on the ROHC overhead. The results are included in Table 2 below. The ECN rate needs to be measured over a number of packets, for example by using a sliding window over the last 100 packets.
TABLE 2Additional ROHC compression overhead as a function of ECN rate.Averageextra overheadAverage extra bitrate (assuming 50ECN rate [%][octets/packet]packets/second) [bps]10.239220.4116350.92369101.75700202.881153504.341734
From Table 2 it is clear that the extra overhead can potentially use a lot of resources, especially when the bitrate is low and the packet rate is high, and therefore potentially defeats the purpose of ECN.
An existing approach to handle this situation is to disregard the extra over-head due to the ECN rate. The Radio Access Networks (RAN) will assign a radio bearer with a certain maximum bit rate based on an estimation of the ROHC compression efficiency. If the RAN does not allocate any margin for the extra ROHC overhead, then it is likely that a UE (User Equipment) in the uplink or an eNodeB in the downlink will exceed the allocated maximum bitrate. A policing function may monitor the utilized bitrate and may perform rate shaping, e.g. by dropping or delaying packets, if the maximum bit rate is exceeded. This introduces packet losses and/or delay jitter that will impact the service quality. If, on the other hand, the RAN does allocate some extra margin for the extra ROHC overhead, then this reduces the number of sessions that can be allowed in the cell, and thus reduces the capacity.